The present invention is generally directed to integrated circuit cards, commonly known as xe2x80x9csmart cards,xe2x80x9d and other types of portable electronic devices that are capable of executing applications, such as PDAs and mobile telephones. More particularly, the invention is directed to the use of such devices for hosting services in a distributed computing system.
As the use of portable electronic devices with integrated microprocessors becomes more widespread, and the technology pertaining to them advances, the amount and variety of information contained in such devices continues to grow, thereby expanding the potential applications for them. In this regard, one particularly interesting application constitutes the use of these devices, such as smart cards, PDAs, and mobile telephones, as hosts for services in a distributed computing system. In this context, the device stores one or more application programs, e.g., applets in the Java programming language. Each such application has a corresponding client program that communicates with the application stored on the device. Typically, the client program might be stored in a terminal in which the device is inserted, or with which the device otherwise communicates. The client programs and device applications exchange messages with one another, and thereby permit a user at the terminal to employ the services provided by the applications on the device.
Typically, in a distributed computing environment, the client and server portions of an application communicate with one another by means of a predefined set of semantics. One example of such a semantic is a procedure call. Another example of a semantic, in an object-oriented programming environment, is a remote method invocation (RMI). In the context of this latter semantic, the functions, or methods, that can be performed by the server program are published, e.g. through an application programming interface, and the client program interacts with the server program by invoking these methods, and providing any parameters that are associated with the invocation. The server program performs the operation that was requested by the client, and returns a result. This protocol facilitates the development of new client programs, since the program developer need only be aware of the published methods for the server program, and write appropriate calls to invoke those methods.
When using a portable electronic device as a host for distributed services, the device may be required to communicate with the client by means of a specific protocol. In the context of a smart card, for instance, the card and the terminal must communicate with one another in accordance with the standards that are applicable to smart cards. Specifically, ISO/IEC 7816-4 specifies that the card and the terminal communicate with a message structure known as the application protocol data unit (APDU). Messages are exchanged as a command and response pair. In the development of applications for the smart card environment, therefore, the program developer was required to be familiar with this message structure, and incorporate code into the program which conforms to the applicable protocol. For instance, the software on the smart card had to include program code which operated to decode command APDUs and encode response APDUs. On the terminal side of the application, the software had to include program code which performed the corresponding inverse operations. Consequently, the development of application programs that were designed to operate on smart cards was quite complex.
To alleviate this burden in the development of applications for smart cards, semantic frameworks have been proposed. For instance, an RMI framework enables programmers to deal with the card applications at the level of method invocations, and not concern themselves with the APDU message passing mechanism. In essence, this result is accomplished by the use of a client proxy at the terminal side of the system. When the client program invokes a method, this invocation is presented to the proxy. The proxy converts the method into the appropriate APDU message, which is then transmitted to the card. At the card, a skeleton program performs the inverse function of the proxy, and transforms the received APDU messages back into the appropriate method calls. These calls are then presented to the on-card application, which returns a corresponding result.
To facilitate the generation of the client proxy and the card skeleton in the Java programming language developed by Sun Microsystems, a programming tool such as a Stub Generator can be made available to programmers. In the context of smart cards, for example, a Stub Generator which is adapted to a subset of Java that is executed on a smart card, known as Java Card, can be employed. In the development of a service that is to be available from a smart card, the programmer develops the implementation of that service, namely, the actual steps of the program that perform the service, as well as an interface which defines entry points of the application on the card, i.e. the list of methods that are available from the implementation. The Stub Generator tool that is adapted to Java Card then generates the client proxy and the card skeleton from the definitions provided via the interface, to provide the appropriate conversions between the published methods and corresponding APDU messages. The card application, which consists of the implementation code, the interface and the card skeleton, is then installed on the card, and client programs are developed which communicate with the client proxy to invoke the methods available through the card service.
The use of the client proxy and card skeleton to facilitate the transport level communications between the terminal and the card provides a number of advantages. First, the card applications can be written in a known language, e.g. the Java programming language. The proxy and skeleton make the APDU protocol transparent to the operation of the program. Consequently, the program developer is not required to have any knowledge of this protocol. As a result, the smart card can be readily integrated into a distributed computing model, rather than having to be treated as a special device.
However, in the context of a smart card, there may be some situations in which it is desirable for the APDU messages to be handled at the application level, rather than in the skeleton. For example, one of the most significant features associated with a smart card is the security that it provides for various transactions. To provide such security, the smart card may encrypt and decrypt the APDU messages, and/or add a signature to each APDU message. To maintain the security level associated with these procedures, it may be preferable to have the encryption and decryption, and/or the validation of signatures, handled within the application itself, rather than develop a specific proxy and skeleton to handle these functions. Further in this regard, it would be difficult to employ a program generation tool, such as the Stub Generator, to automatically produce the required proxy and skeleton. Such a tool would have to be very powerful, and hence complex, since it would have to be familiar with all of the requirements of all of the applications for these types of security services, if it is to operate effectively.
In another situation, it may be the case that older, legacy terminals do not employ the services of a client proxy or an application interface. As a result, these terminals are only capable of communicating by means of the APDU messaging protocol. For instance, the GSM specification for mobile telephones is not based on the Java programming language, and therefore does not employ semantics such as remote method invocation. In such a case, an application which relies solely upon a card skeleton to provide such semantics would not be able to communicate with a legacy terminal.
To address these types of situations, various solutions can be envisioned. As one approach, it is possible to forbid any interaction with the communication messages at the application level, and require them to be handled solely by the skeleton. This approach is not entirely satisfactory, however, because it requires all communication modes to be defined in advance within the skeleton. Since the skeleton is fixed once it has been generated, it would not be able to deal with new advances that are subsequently developed, e.g. a different security protocol.
As an alternative approach, it is possible to permit application developers to modify the skeleton. Thus, as new security procedures are implemented, the skeleton can be adapted to recognize and convert APDU messages associated with the new procedures. Similarly, the skeleton can be modified to handle APDU messages that are sent from legacy terminals. Again, however, this approach presents its own set of problems. First, the modification of the skeleton may prove to be difficult if it is to continue to operate in an error-free manner. Secondly, the programming results that go into the modification may not be reusable, resulting in the expenditure of additional time and effort each time a skeleton is to be modified to accommodate a revision to an application.
As a solution to the foregoing situations, therefore, it is preferable to provide a mechanism that enables an application on a portable electronic device to interact directly with certain types of APDU communication messages that conform to a protocol associated with that device, while at the same time retaining the advantages of a semantics framework. In accordance with the present invention, this objective is accomplished by defining a set of standard entry points that can be employed within an application to receive and interact with protocol-compliant messages. In one implementation of the invention, three such entry points are established as semantics that can be implemented by the application. These three semantics respectively relate to data processing operations, pre-processing operations and post-processing operations.
In the context of a smart card, for example, when the skeleton receives an APDU message from a terminal, it determines whether the card application is capable of pre-processing APDU messages. If so, it forwards the message as part of a request to perform such pre-processing. The application performs any necessary pre-processing, e.g. it decrypts the APDU message, and then returns it to the skeleton. The skeleton then determines if the received APDU message is one which calls a procedure or invokes a method. If so, the message is decoded and the procedure call or method invocation is issued to the application. Alternatively, if the message is not one which is recognized by the skeleton, such as a message from a legacy terminal, it is forwarded to the application with a request to process it. When the application returns a value in response to an invoked method, the skeleton encodes it into an APDU message in the normal manner, and then presents it to the application for any appropriate post-processing that may be required. The final result from the application is then forwarded to the terminal as an APDU response message.
Thus, the present invention provides a mechanism by which an application program can be enabled to directly interact with APDU messages, without requiring its associated skeleton to recognize and convert those messages. The skeleton only needs to discriminate between APDU messages that pertain to semantics defined in the application interface and those which do not, and forward the latter types of messages to the entry points that are implemented by the application.
Further features of the invention, and the advantages provided thereby, are explained in detail hereinafter with reference to exemplary embodiments of the invention illustrated in the accompanying drawings.